使用 NetQ 排除网络故障
EVPN 已成为现代数据中心架构的标准解决方案。对于终端用户来说，受益于基于 BGP 的控制平面所具有的稳定性，EVPN 提供了扩展其广播域的灵活性。但这些增加的益处是以提高配置的复杂性为代价的。
当前所面对的不再是相对固定、简单，可以通过维护人员直观分析来发现错误的网络配置。真正的生产性 EVPN 配置可能包括多个深度嵌套结构，而且随网络中的租户数量成比例增长。
EVPN 配置复杂性可以且必须通过适当的自动化解决方案予以解决，这可以减少人为出错的可能性，而 NVIDIA Cumulus Linux 正是解决该问题的合适解决方案。但仅有自动化还不够，错误仍然可以通过数据源引入系统，例如配置管理数据库（CMDB）的人为错误。
可观察性的重要性
这就是为什么对于任何具有合理复杂程度的基础设施，用户应该有办法来采集各类日志、指标，并且调试、输出、汇总、关联和处理这些信息，从而尝试推断系统的内部状态。实现这一点的能力通常被称为系统的“可观察性”，而且随着底层基础设施复杂性的增加，它正变得日益重要。在 CNCF 云原生环境 中，“可观察性和分析”部分不断增长的项目数量已证明了这一全行业趋势。对此，NVIDIA 也持同样的观点。
图1 数据中心发展历程
通过 NetQ 实现的全网可观察性
长期以来，整个网络的可观察性仅限于拓扑视图——有些图包括从物理链接到 L2，L3 接口再到控制平面协议等不同层次的细节。但这些代表高层次意图的图只有在有人维护时才能保证准确。它们永远无法反映每个设备中所包含的网络的实际状态。NetQ 在设计上解决了这些问题并为整个网络的运行状态提供了一个统一的观察窗口。
一方面，NetQ 从其远程代理处收集和汇总多项指标，这些代理可能运行在网络交换机、通用计算服务器等任何位置。这些指标包括但不限于：接口统计和利用率、LLDP、MAC、ARP/ND 和 IP 路由表、BGP、MLAG 和 OSPF 的控制面状态，以及用于帮助诊断任一数据平面丢包的故障快照（What Just Happened）事件。
另一方面，NetQ 使用这些指标来推断网络的内部状态并作出针对协议的诊断。这些检查包括从简单的MTU和链路状态一致性到BGP和EVPN状态验证再到端到端连接性测试。
故障排除演示
在这篇文章中，将演示如何使用 NetQ 来排除一些使用以下拓扑结构的常见配置错误。叶节点被配置为 MLAG 对，并且该结构内部正在运行带有对称 IRB 的 EVPN 和基于 PIM 的 BUM 复制。
图2 NVIDIA Air 的拓扑结构
环境设置
该测试拓扑结构可以在名为NVIDIA Air的云基础设施模拟平台上启动。如要了解更多信息，请参阅《NVIDIA Air用户指南》。
选择创建模拟、演示市场和使用NetQ的网络故障排除选项卡。
在接下来的部分中，将讨论各种故障排除情景，并展示NetQ如何帮助确定问题的来源。
情景 1：服务器 01 无法与服务器 02 通信
第一个问题很简单：两台服务器都连接到同一对叶节点交换机上，因此需要检查的地方仅限于以下几个方面：
所有服务器链接的L1和Bond接口配置
peerlink 的 MLAG 状态和配置
vlan 10 和 vlan 20 的 L3 和 VRR 接口配置
通过 NetQ，只需点击几下就可以完成所有这些检查。
在模拟页面，选择启动NetQ，输入用户名和密码
在工作台标题中，选择验证并创建一个新的 MLAG 验证。
图3 情景 1 结果
当验证完成后，NetQ发现双宿设备有四个错误。对于每一个出现错误的检查，用户都可以查看更详细的信息并了解NetQ认为的错误是什么。
图 4 情景 1 详细信息
在本情景中，NetQ 清楚地指向接口 bond1 的 VLAN 配置，现在可以通过登录和比较两台叶节点交换机上的配置来进行快速验证和纠正。
用户可按照实验指导来依次解决问题。
情景 2：服务器 01 无法与服务器 04 通信
第二个情景涉及 VXLAN EVPN 结构上的 VLAN 内通信。这种故障的常用故障排除流程可能涉及以下步骤：
确认所有 BGP 会话都已建立，并且所有对等层的EVPN地址族都已启用。
确认所有四个叶节点交换机上的 VLAN 至 VNI 映射是一致的。
确保导出和导入所需的 Type-2 路由使用同一组路由目标。
检查 BGP 是否被配置为发布所有已配置的 VNI。
必须在所有叶节点交换机上比较这些数值。下面将展示用NetQ检查上述信息有多么简单。
在主工作台标题选择选项卡并打开EVPN 会话选项卡。
在全屏视图中打开此选项卡，查看所有会话屏幕（图5）
图5 情景 2 详细信息
现在可以在屏幕上看到所有的相关值，这些值以表格的形式呈现并且可以进行排序及过滤以缩小搜索范围。在该情景中，很容易发现叶节点01/02和叶节点03/04之间 Vlan10 的 VNI 映射差异。
用户可按照实验指导依次解决问题。
情景 3：服务器 01 无法与服务器 05 通信
最后一个情景涉及 VXLAN EVPN 的 VLAN 间对称路由。这次，需要验证的内容有所增加，包括以下额外步骤：
每个 VRF 的 BGP 配置和会话状态
EVPN 5 型路由在叶节点交换机之间的传播
检查 L3 VNI 的配置是否一致以及每个 MLAG 对是否有唯一的 Router MAC
L3 VNI 到 VRF 在所有交换机上的映射
通过 NetQ EVPN 验证功能，所有这些假设都可以在几秒钟内得到验证。
在主工作台标题中选择验证并创建一个新的按需 EVPN 验证。几秒钟后，用户即可看到结果（图 6 ）
图6 情景 3 结果
通过点击 VRF 一致性警告，用户可以清楚地看到错误位置。解决问题的时间缩短到几秒钟，管理员现在可以继续纠正叶节点 03/04 上的 VNI 至 VRF 映射。
图7 情景 3 详细信息
请查看实验室指南，了解解决这个问题所需的具体指令。
总结
在这篇文章中，展示了 NetQ 根据管理设备采集的各种指标来分析和推断网络状态的能力。以上三个情景展示了如何利用 NetQ 的验证和协议专用选项卡将根本原因分析的时长从几分钟或几小时缩短到几秒钟。这些验证可以按需求运行，也可以定期运行，甚至可以在过去的数据上运行，这是因为所有日志都存储在一个时间序列数据库中。
NetQ 的能力远远超出了这篇文章中所展示和讨论的内容，并且其功能还包含设备库存、软件生命周期管理、基于阈值的警报以及与第三方平台（如 Slack、PagerDuty 和 Grafana ）的集成。NetQ 继续扩展并增加更多的功能和第三方集成，在未来为用户创造更多价值。
观看黄仁勋主题演讲重播，更多精彩，欢迎 扫描以下海报二维码！